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We present a synthesis method for communication protocols 
for active safety applications that satisfy certain formal spec- 
ifications on quality of service requirements. The protocols 
are developed to provide reliable communication services for 
automobile active safety applications. The synthesis method 
transforms a specification into a distributed implementation 
of senders and receivers that together satisfy the quality of 
service requirements by transmitting messages over an unre- 
liable medium. We develop a specification language and an 
execution model for the implementations, and demonstrate 
the viability of our method by developing a protocol for a 
traffic scenario in which a car runs a red light at a busy 
intersection. 

Categories and Subject Descriptors 

C.2.2 [Protocol Verification]; B.1.2 [Automatic Syn- 
thesis] 

Keywords 

Vehicle-to-vehicle communication; Discrete controller syn- 
thesis; Active safety 

1. INTRODUCTION 

Active safety systems have the potential to transform au- 
tomobile traffic by complementing a human operator's capa- 
bilities to prevent accidents and increase efficiency [4] . Com- 
munication between cars enables cooperative safety applica- 
tions by further augmenting information gained from local 
sensors. Examples for active safety applications are traffic 
signal violation warning, cooperative collision warning and 
electronic emergency brake light [4, 11]. 

By transmitting information between each other, cars can 
gain a view of the traffic situation more refined than it would 
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be possible merely with sensors [8], because global informa- 
tion about traffic is being made available locally to the cars. 
Such information can be used in active safety systems to 
avoid accidents and even improve traffic efficiency by en- 
abling both communication with the infrastructure and be- 
tween cars [3, 4, 6, 21, 22]. 

Depending on the active safety application, different types 
of vehicle-to-vehicle (V2V) communication paradigms have 
been investigated. Safety applications often require to main- 
tain continuous tracking of other cars in the vicinity, which 
is typically done by having cars broadcast information about 
their position, velocity and other parameters of their state in 
regular intervals [11]. Vehicle Ad-Hoc Networks (VANETs) 
using routing protocols such as Geocasting or Ad-Hoc Dis- 
tance Vector (AODV) handle applications involving several 
cars in a peer-to-peer (P2P) connection [9, 13, 15]. The 
main challenge is to maintain reliable communication in the 
presence of possible channel congestion if several cars use 
the transmission medium simultaneously [9, 14]. 

Traditionally, in the development of communication pro- 
tocols, the programs are implemented manually, and veri- 
fication of the protocol is only done after prototyping, ei- 
ther through testing or model checking [7, 2, 20]. A slight 
improvement over this bottom-up approach is to develop a 
framework for distributed protocol specification and auto- 
matically generate inputs to model checkers and theorem 
provers [19]. 

In contrast, synthesis finds the programs to be executed 
on each car directly from a global protocol specification. In 
this approach, the synthesis method is guaranteed to gen- 
erate distributed implementations that satisfy their speci- 
fication by construction. However, so far only small prob- 
lems have been considered in synthesis without particular 
applications in mind [17, 16, 10]. Also, protocol implemen- 
tations are only valuable in practice if it is clear under which 
assumptions they are correct and if the communication re- 
quirements are clearly specified [9]. Only if a precise model 
of the environment is provided, i.e. the worst-case behavior 
of the transmission medium, is an argument of correctness 
convincing. 

Synthesis is made difficult on the one hand by distributing 
a single global specification in a way that the distributed im- 
plementation operates correctly in an adverse environment, 
and on the other hand by having to ensure correctness of 
the results, which has to be ensured for any valid protocol 
specification given as input to the synthesis. 

Our main contribution is the development of a method 
that automatically translates global specifications of the pro- 




Figure 1: Intersection scenario: Car A runs the red 
traffic light. Hence car B (and potentially other 
cars) must stop. Other cars at the intersection may 
be transmitting over the wireless medium at the 
same time, which has a deteriorating effect on the 
communication between A and B. 

tocol into implementations that formally guarantee the de- 
sired quality of service requirements under the environment 
assumptions. Specifically, we develop a synthesis method for 
reliable asynchronous communication protocols with clearly 
defined interfaces that can be used in a layered design. We 
focus on providing communication services to enable active 
safety applications for cars and therefore lump any active 
safety activities into an abstract higher level that interacts 
via strictly defined interfaces with the lower level communi- 
cation services that we develop. 

Our work addresses several shortfalls in previous work 
on protocol synthesis [5, 12, 17, 23]. We introduce a for- 
mal specification language to allow a textual representation 
of the protocol specifications, which are typically given in 
graphical form. Moreover, we make precise the semantics of 
protocol specifications and their implementations that are 
usually only informally described. 

2. COMMUNICATION 

Consider the scenario of two cars wanting to communi- 
cate with each other at an intersection, c.f. Fig. 1. One 
major complicating factor for reliable V2V communication 
is that the cars are constantly moving and have to commu- 
nicate over wireless links. Cars that intend to communicate 
share restricted bandwidth availability with all other cars 
within reach. When constantly tracking cars using broad- 
casts, scalability is limited by the susceptibility for flooding 
and frequent message collisions [14], and by having to keep 
track of the state of every car. 

It would be desirable to be able to implement communi- 
cation protocols that guarantee the correct transmission of 
data even in the presence of a large number of other cars. 
We therefore consider initiating communication on-demand 
when required by an active safety application in an emer- 
gency. In this approach we do not track every car but only 
exchange information when required. This approach has 
the advantage that traffic on the network is lower, more 
predictable, and reliability guarantees can be provided, as 
demonstrated in this paper. We adopt an approach in which 
the sender is responsible for correct delivery by retransmit- 
ting data when a package drop is detected [18] . 

When considering a V2V communication between two cars, 
we do not explicitly consider the behavior of all other cars. 



Since from the point of view of the transceivers it is only 
relevant whether a message is correctly received, we lump 
together the behavior of all other cars that are not directly 
involved in the communication and consider them as a single 
environment. Our method allows us to explicitly state the 
assumptions on this environment under which the protocol 
has to perform correctly. 

Communication between cars is governed by a set of rules 
summarized as a protocol. After a data transfer is initiated, 
messages are transmitted and received in order to guarantee 
a reliable delivery. A protocol is implemented by equipping 
each car with a communication service automaton (CSA), 
which can be seen as a building block or "controller" han- 
dling all communication activities. Hence, the protocol can 
be seen as a building block with clearly deflned behavior 
and interfaces to its environment consisting of higher level 
active safety components (ASCs) and to the lower level that 
handles the transmission of the messages over the physical 
medium. 

Each CSA operates locally, i.e. it can only interact with 
the sensors and actuators of the car it is located on. How- 
ever, since a communication protocol defines events poten- 
tially involving several cars, CSAs need to interact with each 
other. This interaction is done by transmitting messages be- 
tween the cars e.g. using wireless transceivers. 

Defining a clear hierarchy of layers is inspired from the ISO 
OSI architecture prevalent in most modern communication 
networks [24]: A network layer is dedicated to establishing 
host-to-host connections with basic quality of service (QoS) 
guarantees. A data-link layer is layered below the network 
layer and provides error-corrected single hop connections. 
Above the network layer is the transport layer, that among 
other services provides the destination address of a message 
and QoS requirements. We consider an abstraction in which 
a car's ASC contains the transport layer and all above layers. 
The ASC specifies parameters such as the data to be sent, 
the destination address, and limits on transmission delay. 

3. SETUP 

Developing a synthesis method requires a formal speci- 
fication language for protocols and a modelling framework 
to formally describe executable CSAs. Moreover, the CSAs 
should include interfaces to their corresponding ASCs at the 
higher level, and hence our synthesis method is designed 
to introduce this inter-level interaction. To illustrate our 
method we will use the following example motivated by 
Caveney [4], and Farkas et al. [8]: 

Example 1 Consider the scenario of cars at a road in- 
tersection shown in Fig. 1. Car A runs a red traffic light, 
and car B approaches the intersection on a trajectory that 
would lead to a collision. The two cars have to communi- 
cate in order to avoid an accident. At the intersection there 
might be other cars that share the same broadcast medium 
and hence might interfere with the communication between 
A and B. □ 

3.1 Operation of a Protocol 

The primary objective of a communication protocol is to 
transfer information between cars. Information transfer be- 
tween two cars can be interpreted as synchronizing two local 
events between the cars. Events are indexed by elements e 
from a set £. An event e may be associated with data d 
from a set V, written e(d). T> contains an auxiliary element 
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Figure 2: Two cars A and B communicating with 
each other: A sends a message (by calhng snd^^^(fi)) 
and B responds with an acknowledgement on recep- 
tion (by calling ack p , ^). The transmission medium 
and the ASCs are the environment of the CSAs. 

-L, indicating the absence of data. We simply write e for 
notational convencience if S =_L in e(d). 

A local event is an event that is triggered either by the 
ASC of a car (an environment-triggered event from the point 
of view of the CSA), or by the CSA of a car itself (a system- 
triggered event). An environment- triggered event that is 
initiated by the ASC at car A and is to be synchronized 
with car B is written as lA-i-s i^)- It is synchronized with the 
corresponding system-triggered event eg^^id) by the CSA 
of car B. The sets of environment-triggered and system- 
triggered events are written as £e and £s respectively. 

If (_a^bW oil ^ is synchronized with ^g^^id) on car 
B, then the data d is transferred from ^ to B. This is sum- 
marized as a single global event eA^sid) (note the absence 
of the lino under e). The set of global events is denoted by 
£g- a protocol specification defines a desired temporal or- 
der on such global events. Since global events involve several 
cars, a protocol specification is centralized, i.e., it is assumed 
that the actions of all cars can be influenced independently 
by a single controller. 

Synchronization is achieved by sending messages across 
a shared transmission medium. A CSA interacts with the 
medium by transmitting messages and waiting for reception 
of messages. A message transmission is indicated by "!!", 
while a reception is indicated by "?" prefixed to a message. 

The interaction with the higher-level ASC is managed by 
calls and upcalls. A call is initiated by the ASC and causes 
an environment-triggered event in the CSA. An upcall is 
initiated by a system-triggered event in the CSA. 

Example 1 (Continued) Consider again the intersec- 
tion problem in Fig. 1. As car A is approaching the inter- 
section, it needs to establish whether it is safe to enter the 
intersection. It therefore wants to establish a communica- 
tion with any car that might pose a safety hazard. 

Car A needs to communicate with car B to find out if B 
is willing and able to stop or whether A should attempt an 
emergency brake. Each car is assigned a unique address for 
labelling messages, so that when a car receives a message, 
it knows whether it is the intended destination. We assume 
that the ASC at A provides its CSA with the address of B, 
so that a P2P communication with B can be established. 

This communication scenario is shown in Fig. 2, where the 
CSA associated with each car is shown as a box. Data d is 
transferred from Ato B, and B should send an acknowledge- 
ment back to A. Sending d from j4 to S is done by synchro- 
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Figure 3: The protocol on two levels of detail. 

nizing the local events snd p (d) and snd p,__ ^ (d), while the 
acknowledging synchronizes ack ^ ,p with ack p, 4. A call 
by an ASC triggers the corresponding environment-triggered 
event in the CSA on the same car, while an upcall is initi- 
ated by the CSA when some system-triggered event requires 
the attention of the higher level. □ 

3.2 Quality of Service 

Depending on the application, it is be necessary to guar- 
antee that a transmission is completed with certain require- 
ments on particular aspects such as end-to-end delay, mes- 
sage drop probability or bandwidth. These aspects are called 
Quality of Service (QoS). We are concerned with automat- 
ically implementing protocols that guarantee that certain 
requirements on QoS are met. 

Whether QoS requirements can be satisfied depends on 
the properties of the medium used to transmit messages 
over. In our work we assume minimal capabilities for a 
transceiver, so the only way to satisfy QoS requirements is 
to select the appropriate frequency and number of retrans- 
missions for messages. 

Also, when finding the CSAs that satisfy the protocol, 
we have to take into account that the performance of the 
transmission medium typically degrades as consequence of 
messages being transmitted. Moreover, a car cannot predict 
the behavior of the transmission medium merely on the basis 
of its own actions, since there might be other cars sharing the 
same medium that exhibit unpredictable behavior from the 
point of view of the car. In Example 1, while cars A and B 
are communicating, other cars might be trying to transmit 
messages itself, leading to a degradation in performance for 
A and B that neither car can predict. 

We restrict the package drop probability A of the trans- 
mission medium by assuming that it is below a given thresh- 
old probability 6 at all times. We write this as □(A < 5), 
where "□" is the always operator "□" of linear temporal 
logic (LTL) Hence, a full specification in the framework 
can be stated as an assumption/guarantee specification [1] 
□ (A < 5) — > where a protocol specification ip only has 
to hold as long as the assumption that at all times A < 5 is 
satisfied. 

A straightforward extension to take time into account 
would be to consider each (re)transmission to take up some 
amount of time T. We can then include another assump- 
tions of the form □(T < Tmax), where Tmax is an upper 
bound on the transmission time. 

4. TECHNICAL APPROACH 

In this section the concepts described above are formal- 
ized. 

4.1 Protocol Specification Language 

In a protocol specification, the protocol is viewed as a 



single component interacting with the ASCs, cf. Fig. 3(a). 
Only the interaction across the interface between ASCs and 
CSAs is specified. The CSAs, representing an implementa- 
tion of a protocol, then interface with the lower level trans- 
mission medium in order to provide the required services to 
the higher level. In this way, the ASCs never come in di- 
rect contact with the transmission medium. As introduced 
above, a specification of the protocol is given as a temporal 
(partial) order of global events. A global event is any event 
involving the interaction of several cars, such as a message 
transmission (involving both the sender and the receiver). 

Hence, a protocol specification can be seen eis an allowed 
set of sequences of global events. Moreover, each sequence 
is tagged with a QoS requirement, which, in our case simply 
is the required probability of the sequence to be synchro- 
nized correctly. In order to avoid having to write a list of 
sequences with potentially many global events repeating, we 
use the following temporal logic-like language to define pro- 
tocol speciiications: 



if ■.:= e'^\e ■ 



Oip\ifiV(p, 



where is a global event e € So together with a probabil- 
ity p indicating the required QoS. Extensions of this speci- 
fication language can also include time, bandwidth or other 
QoS requirements in the same way in the specification. A 
speciBcation is a protocol specification together with an en- 
vironment assumption, in our case an upper bound 5 on the 
drop probability A. 

Example 1 (Continued) The protocol described in the 
intersection example of Fig. 1 can be specified as 



ip = sndA^s(d) 



0(ack^'_^^ V nackg'_^^). 



(1) 



which can be illustrated as a tree as in Fig. 4. In the nu- 
merical results presented later for this example we will use 
different values for pi and p2. 

The results of the synthesis also depend on the drop prob- 
ability bound S. A complete specification that includes the 
assumptions on the transmission medium dynamics would 
be 



□(A <d) ^if. 



(2) 



□ 



Since we are interested in QoS requirements over the drop 
probability of the transmission medium, a probability p on 
e'' labels each leaf of the tree representing a protocol spec- 
ification, specifying the desired probability of the (unique) 
sequence of global events a occurring that leads to the leaf. 
We call a sequence a with a probability p attached to it a 
p-sequence and write {crY- The semantics of the protocol 
specification language is defined by a satisfaction relation: 
If a p-sequence a of global events satisfies the protocol spec- 
ification ip, this is written as {aY \= P- 

We first develop an intuitive understanding of a sequence 
(J = eiC'z ■ ■ ■ satisfying a specification p. Recall that a proto- 
col specification only takes the interfaces between CSAs and 
ASCs into account, and hence views the protocol implemen- 
tation as a monolithic entity as in Fig. 3(a). Each global 
event d = tx^y{d) in the sequence cr is interpreted as the 
synchronization of an environment-triggered event (^^^y{d) 
and a system-triggered event <^y^^{d). The ASC on car x 
triggers (^^y{d) by a call to its CSA. The intention is that 
the corresponding system- triggered event ej,^_a,(rf) is syn- 
chronized with that event in the CSA on car y (and an upcall 
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Figure 4: Visualization of protocol specification ip 
in (1), which establishes a partial order between the 
global events snAx^y{d), ackj,-»a; and nackj;->.a;, repre- 
sented by the order of the edge labels. 

is made to its ASC). The synchronization is correct if after 
an environment-triggered event e,j.^y{d), the first system- 
triggered event is ty^^id), i.e. no other system-triggered 
event is interleaved between them. Note that environment- 
triggered events that do not correspond to global events in 
the specification may be interleaved, as the protocol has no 
control over the higher level. Then, the statement (cr)'' |= ip 
expresses that a satisfies the partial order defined in ip and 
has a high enough probability p attached to it. 

We now formally define \= recursively on the structure of 
a protocol specification p (cf. (1)); 

(e)'' he" ^ P>q 

(^e,ar Ne^Ov' ^ {(^T h ^ (3) 
(a)P ^ pi W p2 ^ (cr)f ^ pi or {af ^ p2, 

where adding a global event e to the head of a sequence a is 
written as e,a. Under these semantics a protocol specifica- 
tion is satisfied exactly by those sequences of global events 
that both obey the partial order induced by ip and that have 
a sufficiently high probability attached to them. 

4.2 Communication Service Automata 

We are interested in finding a way to implement a pro- 
tocol in a distributed manner by finding CSAs for the cars 
so that their joint execution satisfies the protocol specifi- 
cation. That is, the implementation of the protocol must 
use the transmission medium in order to guarantee the re- 
quired services to the higher level, see Fig. 3(b). A set M 
of CSAs satisfies a protocol specification if it produces only 
the allowed sequences of global events, and these with a suf- 
ficiently high probability. In this section we make precise 
the concept of a CSA and define its semantics in the next 
section. 

A CSA is a finite state machine with labelled transitions, 
which is similar to a protocol entity specification used by 
Ishida et al. [12]. Transition labels either indicate which 
actions should be executed when the transition is taken, or 
impose conditions on a transition. A transition for which 
all conditions are satisfied is called enabled. The labels that 
are available to the synthesis method are explained below, 
and transitions are typically labelled with combinations of 
labels. 

Firstly, interaction with the higher-level ASCs is encoded 
by edges labelled with environment-triggered and system- 
triggered events. We also introduce two special system- 
triggered events " fail " and " success " to £$ that have no cor- 
responding environment-triggered events to be synchronized 
with. The purpose of these events is merely to inform the 
ASC of the outcome of a transmission. A fell event indi- 
cates that allowable retransmission count is exceeded, while 
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Figure 5: Two CSAs that realize the protocol spec- 
ification in (1). The transitions are labelled with 



broadcast messages (e.g. 



>s(d))5 receptions (e.g. 



?aB-s-A(rf)), and local events (e.g. snd ^^p(d) and 
snd p yA^ (d)). Initial states and final states are shown 
as doubled and dotted circles respectively. In each 
retransmission loop, a retransmission counter Vi is 
increased by one on each timeout or reception. The 
transmissions are conditioned on the retransmission 
counters i^i. If the counter is exceeded, indicated by 
i/j > ni, a fail j occurs. 

the success event indicates a successful transmission to the 
ASC triggering the last global event. ^ 

Secondly, to interact with the transmission medium, tran- 
sitions can bo labelled with message transmissions and re- 
ceptions. Each message has a unique identifier rn. A broad- 
cast message is written as [\mx^y{d), where x and y arc the 
source and destination respectively, and d £ V is the data 
transmitted. It is read as "send m with data d to y from 
source x." Similarly, a reception is written as "^myi-xid), 
where x, y and d have the same interpretation as for a broad- 
cast message. It is road as "rocoivo m with data d from x 
destined for y." Again, if d =-L, the parameter is not written. 



^This is necessary since no response from another ASC can 
indicate completion of the transmission. 



Define B and TZ to be the set of broadcasts and receptions 

respectively. 

Lastly, we introduce labels for internal actions of a CSA. 
In order to satisfy the QoS requirements of the protocol 
specification, it may be necessary to allow the retransmis- 
sion of messages. To this end, we dc^fint? a set of variables 
V over No = {0,1,2,...} that act as rctrausinission coun- 
ters. We will construct the CSAs in such a way that for 
each message m that might be retransmitted, after a trans- 
mission ]\mx-^y{d), either a reception of some other message 
is expected or a timeout "T.O." may occur. On the time- 
out, the retransmission counter v of the message is increeised 
by one. If exceeds its retransmission bound n G No, the 
transmission fails, causing a fail event and a corresponding 
upcall informing the ASC. We write an update of a vari- 
able v € V as v + +, and denote the set of updates by 
U = € V}. Further, a transition may be labelled by 

a condition on a retransmission counter, which can be either 
of the form v < n ot v > n. The set of conditions is defined 
as C = txi n|!/ e V, cxiG {<, >}, n G No} 

When synthesizing a CSA from a protocol specification, 
each transition can be of one of seven kinds, depending on 
the labels: A environment-triggered event, a conditional 
system-triggered event, a timeout with a system-triggered 
event, a timeout with update, a conditional broadcast, a re- 
ception with a system-triggered event or a reception with 
update. Hence, the sot of labels is S = U {£s x C) U 
({T.O.} X £s) U ({T.O.} X W) U (B X C) U (7^ X £s) U (7^ x W) 
for the respective cases. The set of such transition labels is 
denoted by E. A CSA M is a quintuple 

M ^ {S,V,s'"'\Sf,T), 

whore S* is a set of states labelled by valuations of variables 
V, s*"" G S is the initial state, C 5 is the set of final 
states, and T : 5 x E — ^ 5 is the (partial) transition function. 

Example 1 (Continued) The pair of CSAs shown in 
Fig. 5 represents one potential implementation of the proto- 
col specification in (1). The transmissions and receptions are 
introduced in order to ensure that the QoS requirements as 
defined in the specification is preserved by the CSAs that can 
only communicate over the transmission medium. For exam- 
ple, the sender Ma may retransmit the message !!aA^s(d) 
up to ni times in case of repeated timeouts to increase the 
likelihood of a successful transmission, in order to meet the 
specification. □ 

4.3 Semantics of CSAs 

In the semantics of a CSA, we want to reflect that a car 
should be able to execute it as a controller for its wireless 
transceiver. 

Decisions when to make transitions should bo based only 
on information available locally. For example, a transition 
labelled by a reception Inix^y is taken only when a message 
m axrives that has x as its destination and y as its source. 
Since a CSA is executed locally on a car, we first define the 
local semantics of a single CSA. This describes how a CSA 
operates in isolation when receiving calls from the ASC on 
the same car, and messages from the transmission medium, 
cf. Fig. 3(b). We then define the global semantics of sev- 
eral CSAs that operate together, which requires to take the 
transmission medium dynamics into account, cf. Sec. 3.2. 
Hence, the global semantics can be interpreted as defining 
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{p,s) ^^My (p + T.O. + e^^,(d),s') 
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Table 1: Local semantic rules for deducing behavior 
of a single CSA My. 

the behavior of the protocol in Fig. 3(a). An example of how 
the semantics arc used is presented in Sec. 5.2.3. 

4.3. 1 Deduction Rules 

For ease of presentation, the semantics are defined as a 
set of deduction rules. A deduction rule is of the form 



Hi H2 



C 

which is the same as Ar=i ^» ^ ^-^^ conclusion C 
follows from the hypotheses Hi, H2, . . . , Hn- A deduction 
rule can be applied if all its hypotheses hold. Rules can ei- 
ther be applied forward, starting from one or several axioms, 
or backwards, starting from a conclusion. Forward applicar 
tion corresponds to simulation, while backwards application 
corresponds to verification. 

4.3.2 Notation 

We first introduce some notation to make the statement 
of the rules more compact. Retransmission uses conditional 
transitions and updating of variables. The value v of a vari- 
able z/ € V in a state s is written s{v) = v. In the initial state 
gimt variables vaJuate to zero. A condition 7 = 1/ ixi n is 
satisfied in state s, written 7(5), if and only if s(i/) txi n. Two 
states s and s' are equivalent on their values of the variables 

in C V, written s « s', if and only if \/iy G V.s{iy) = s'{u). 

We write r(s,?) « s' if and only if T{s,<,) = s' and s ^ s' , 
where f G E may stand for any transition label. Further- 
more, we use the -|- operator to append an element to the 
end of a sequence. 

4. 3. 3 Local Semantic Rules 

The local semantics is defined by a relation >-m^ 

(E* X 5) X (S* X S) between sequences of transition labels 
and CSA states. The statement (p, s) )-m (p', s') means 



that AI at state s transforms p into p' by making a single 
transition to state s' . It holds if and only if it is dcducible 
via the rules given in Table 1. To make the statement of 
the global semantics simpler, we may label the relation by 
a superscript to distinguish which rules are applied. For ex- 
ample, 5-M indicates that cither the rule [env], [sys-c] 

or [b-c] are applied. If the superscript is omitted, any rule 
may be applied. 

We explain the [env] rule for CSA My in detail, the other 

rules are similar. The hypothesis T{s,ey^^{d)) ^ s' ex- 
presses that My must allow a transition from s that is la- 
belled with the environment-triggered event Sy^^id) and 
leads to a state s' in which the values of all variables in 
V axe the same as in s (i.e. there is no update). If this hy- 
pothesis is satisfied. My at state s transforms p into p' by 
making a transition to state s' . 

The [env] rule can be applied at any point if a transition 
labelled by an environment-triggered event is enabled. It 
is not dependent on an input from the higher level ASC. 
Stating the rule this way is sufficient for our presentation, 
but it can be substituted by 



ns,^y 



to explicitly require an input to be able to apply the rule. 
The input is the last element in the sequence, which is 
an environment-triggered event Sy^^id), indicating that the 
ASC must have made the corresponding call. This input 
may be placed in the sequence (i.e. added as last clement) 
by the global semantics, similar to the inputs for the [r-sys] 
and [r-upd] rules. 

The [sys-c] rule places no restriction on the input and con- 
tains as an additional hypothesis that the condition 7 must 
be satisfied in state s. The system-triggered event ^y^-^id) 
gives rise to an upcall. Such outputs can be read off the last 
element of the deduced sequence and hence are not modelled 
explicitly in these rules. The [to-sys] rule can be applied 
for a transition labelled with a timeout T.O. and a system- 
triggered event Sy^-^id). In the [to- upd] rule the value of 
the variable u € V is incremented by one as the transition 

V\{v} V 

is taken. Hence we use the operator ~ , since « would 
indicate that all variables in V retain their values as the 
transition is taken. The [b-c] rule can be applied for a con- 
ditional broadcast message. The outgoing message again can 
be obtained from the last element of the deduced sequence. 



Rules [r-sys] and [r-upd] require the reception 



,{d) to 



occur, hence the rules require the corresponding input. 

Each CSA may deduce a set of sequences of events by tran- 
sitioning between its states. Decisions between environment- 
triggered events, receptions and timeouts are made by inputs 
(or the absence thereof) rocoivod cither from the higher level 
ASC or the lower level transmission medium. These inputs 
can only be generated by the global semantics. 

4.3.4 Transmission Medium Modelling 

We define the global semantics by modelling how the trans- 
mission medium operates. That is, we define the behavior 

of the protocol in Fig. 3(a) by composing the behavior of 
the CSAs in Fig. 3(b) and abstracting away all lower level 
detail. The global semantics defines when inputs to a CSA 
are received from the transmission medium, and restricts 
the valid interleavings of locally generated sequences. The 



[trans] 



[drop] 



[pr-e] 



[pr-t] 



[npr] 



{{p + s, y) =>M(S) {{pT~'^', slz ^ 4], z) 
{p+?Tn,^Jd).s,) -^^M- {p',s':) 

{{p + <;r,s,y) ^MiS) {{P)'"^^ 

^{{p+7m^^y{d),S:.) — - — ^M, {p',s'^)) 

<; =\\my^zid) {p,Sx) > M^ {p',s'^) 

{{p + ?)^, s, y) =^M(S) {{py, s, z) 

<;T^\\my^^{d) {p + ';,Sy) ° > My{p',s'y) 
{{P + 'if, s, y) =^M(6) {{p'Y, s[y -i- s'y\,y) 

? ^\\my^^{d) -.((p + ?, sy) —^My {p", 4')) 

{{p + ^Y, s, y) ==>M{S) {{p'Y, 4y ^ s'y],y) 



<^ ^\\my-^z{,d) ^{{p + ';,Sy) 



e,t 



-^My {P",s'y)) 



{{P + y) =^M(S) {{p'Y, 4^ s'x],x) 



Table 2: Global semantics for deducing behavior of 
several CSAs Ai. In particular, the rules [trans], 
[drop] and [nacc] model the transmission medium. 

medium therefore also acts as an arbiter or scheduler of tran- 
sitions. 

In the global semantics, we axe interested in ensuring that 
several CSAs together satisfy the global protocol specifica- 
tion by interacting with each other. We therefore define the 
semantics of a list of CSAs A4 = {Ma, Mb ■ ■ ■) that is exe- 
cuted together on the respective set of cars £ = {A, B, . . .}. 
Each execution starts with all CSAs in Ai being in their 
initial state s'"'* = (s™'*, s^'*, . . .) and making only tran- 
sitions allowed by the semantics. Only a single sequence 
p € E* is deduced, which is an interleaving of the sequences 
deduced locally. The deduction rules also express that the 
medium transmits messages only with a given probability. 
Hence, the deduced sequence p is tagged with a probability 
p, indicating how likely it occurs. 

Not only do the global semantics define how messages are 
transmitted, also the valid interleavings of locally deduced 
sequences are restricted. To motivate this, consider in Fig. 
5 the execution of the environment-triggered event ack p 
Since time is abstracted away, the transition may be delayed 
by an arbitrary amount of time. However, then the retrans- 
mission loop in the sender A cannot reliably increase the 
likelihood of a successful execution, since the timeout tran- 
sition can also be taken at any time. In order to prevent this 
from happening, the global semantics ensure that transitions 
that are not timeouts or receptions are taken immediately 
if enabled. Hence, only one CSA is allowed to make tran- 
sitions until a timeout or reception is encountered. Then 
any CSA may make a transition. This is incorporated in 
the global semantics by always prioritizing one CSA is to 
make a transition. If this CSA has no transition enabled, 
any other CSA may make a transition. 

4.3.5 Global Semantic Rules 
In the global semantics, we are interested in ensuring that 



several CSAs together satisfy the global protocol sjjcxifi- 
cation by interacting with each other. The transmission 
medium therefore acts as an arbiter or scheduler of transi- 
tions. Hence, we can think of the global behavior of several 
CSAs Ml , M2 , ... as an interleaving p of the locally gener- 
ated sequences pi, p2, ■ ■ ■ of the respective CSAs. Messages 
are only transmitted with a certain probability. Hence, the 
sequence p is tagged with a probability p, indicating how 
likely it occurs. 

The relation {{pY,s,x) > m(s) {{p'Y ,s',x') defines 
the global semantics according to the rules in Table 2. It 
means that M with drop probability 5 at state s transforms 
p into p by making a transition to state s' while the priority 
changes from Mx to M^' ■ In the statement of the rules, 
updating the clement in state s = {sa, sb, ■ ■ ■ , Sz, ■ ■ ■) 
with s'z is written as s[z .s',,]. 

The [trans], [drop] and [nacc] rules define the transmis- 
sion medium dynamics. If the last deduced element in the 
sequence is a broadcast message, i.e. ? =\\my^z{d), the 
medium tries to transmit. An application of the [trans] rule 
models a successful message transmission. This only occurs 
if the CSA for which the message was destined, makes a 
transition labelled with the corresponding reception. That 
is, {p+?rnz^y{d), Sz) — - — >m^ (p', s') is only satisfied if Mz 
can execute [r-sys] or [r-upd]. Since a message transmission 
occurs with probability 1 — <5, the probability with which the 
sequence p' is tagged in the conclusion of [trans] is (1 — 5)p. 

An application of the [drop] rule models a dropped mes- 
sage. It has exactly the same hypotheses as [trans], but its 
conclusion reflects that no progress has been made. The 
sequence p is tagged with Sp due to the message drop prob- 
ability 5. Note that the priority is at the source CSA My, 
which may now execute a timeout transition (if enabled) . 

The [nacc] rule is applied when a message should be trans- 
mitted, but the destination CSA has no transition enabled 
that is labelled by the corresponding reception. Similar to 
the [drop] rule, no progress is made. Also, the probability 
of the deduced sequence is not affected. 

The [pr-e] , [pr-t] and [npr] rules may be applied if the last 
element of the sequence is not a message transmission. Then 
the transmission medium is inactive, and and the CSA that 
is currently prioritized may execute: If a transition that is 
not a timeout or reception is enabled, then Jpr-c] is applied. 
If a timeout transition is enabled, then [pr-t] is applied. The 
[npr] rule may only applied if the currently prioritized CSA 
has no such transitions enabled. In this case, any CSA Mx 
may execute. 

The transitive closure {{pY,s,x) '' m(s) {ip'Y ,^',^') 
denotes that (p, s) is transformed into {p',s') in an arbi- 
trary number of deduction steps. The CSAs M execute by 
starting in state s'"'* with an empty 1-sequence (•)^ and 



any CSA Mx prioritized. 
{{pY,s,y) for which ((•)^ 



Valid deductions are the tuples 

s-«,x> =^*M(,) {{pY,s,y). 

Note that an example of how the local and global semantic 
rules are used is included in Sec. 5.2.3. 

4.3.6 Global Event Sequences 

By applying the deduction rules, sequences over both envi- 
ronment-triggered and system-triggered events, broadcasts, 
receptions and timeouts can be obtained from a set of CSAs. 
Since protocol specifications are over global events, we need 
to extract the synchronizations of local events in the se- 
quences generated by a set of CSAs. We therefore define 



the projection function |-] : E* — t- to find a sequence 
over global events from p. It is defined by 



•1 



[p + i 



[p'l + 



.(d) if W = [p'l+e^^,(d) 
andr = e^^^(d) 
otherwise. 



We use the projection function [•] to express whether a set 
of CSAs satisfies a protocol specification tp under the envi- 
ronment assumptions □(A < 5). 

4.4 Correctness 

In this section we define correctness of a protocol's im- 
plementation in form of a set of CSAs M with respect to a 
specification □(A < 5) ^ '-p. \i M satisfies this specification 

this is written as 7V( h □(A < 5) — > Correctness depends 
on the probability of sequences a being synchronized cor- 
rectly by the CSAs M if the transmission medium's drop 
probability A is bounded from above by 5, i.e. it satisfies 
□(A < 5). If this assumption on the transmission medium 
is not satisfied, the specification □(A < 5) — > is trivially 
satisfied by any set of CSAs. However, this case is useless in 
practice, as the protocol will not deliver the data with the 
required QoS. 

4.4.1 Definitions 

Given a protocol specification (p, correctness of an imple- 
mentation depends on whether all CSAs involved in synchro- 
nizing a sequence of global events are in a final state. We 
therefore define the set of globally final states to include 
all tuples of states {sa,sb, . . .) G Ili^gc so that if there is 
some sequence involving CSAs x,y, . . ., the states Sx,Sy,. . . 
are actually final states from Sl , , . . .. 

We say that a p-sequence (p)^ is generated by a set of 
CSAs M and drop probability 5, and write (p)^ \= M{5), 
if it can be deduced by the rules in Table 1 and Table 2 
and the deduction ends in a globally final state € Sj^^. 
Formally, 

(pY h M{S) ^ 



3s^€SX,.3x,2/€(!:.{(.)\s*"«,a;) 

As noted above in Sec. 3.1, a p-sequence (cr)^ satisfies a 

specification ip exactly if the probability p that all (global) 
events in a are correctly synchronized is high enough given 
that the corresponding environment-triggered events arc all 
triggered through calls by the higher level ASCs. For a set of 
CSAs therefore to satisfy a specification, it is required that 
the synchronization of events in each sequence is performed 
with high enough probability. 

4.4.2 Correctness Condition 

The important criterion for correctness is not whether 
a sequence p is generated, but whether the QoS require- 
ments are satisfied. This is because the decisions between 
environment-triggered events (which essentially generate the 
sequence) are made by the higher level ASCs, over which a 
CSA has no control. For example, in Fig. 5, the receiver 
CSA has no control over whether ack p ,^ or nack g is 
triggered by its ASC in state S2. In our case the only QoS 
requirement is the probability of all global events being cor- 
rectly synchronized, so the question for correctness becomes: 



Given that the ASCs trigger the events necessary to generate 
a, how likely is it that all synchronizations performed? 

M might generate a given sequence a in many different 
ways, since several sequences p deducible by the rules in 
Table 1 might satisfy [p] = cr. For a sequence cr, we evaluate 
the sum of all probabilities p for distinct sequences p that 
satisfy 

cond(a, p, S, M) ^ ([p] = a A (pf H M{S)), 
and get the probability 

cond((j,p,5,A1) 

expressing the likelihood of the events in the sequence a 
being correctly synchronized when executing all CSAs in A4 
in parallel (i.e. using the global semantics). Correctness 
then is expressed by 



M h □(A <S)^ip^ ya.i^q.ia)" \= >p) ^ (cr) 



i.e. if a is a sequence allowed by the specification ip, M syn- 
chronizes the events a at least as likely as it is required. 
The algorithmically challenging part in establishing correct- 
ness is to evaluate r{a,5,M). However, we only need to 
compute this for the CSAs that we are synthesizing. 

5. SYNTHESIS 

The protocol synthesis method & translates a specification 
into a set of CSAs that is guaranteed to satisfy the specifica- 
tion. The inputs to the synthesis are a protocol specification 
p, a set of cars £ and the specification on the transmission 
medium dynamics □(A < 5). &{'Pi £, 5) produces a CSA for 
each car a; e £ that interacts with the higher level ASCs as 
outlined in Sec. 3. 

5.1 Realizability and Well-Posedness 

Synthesis is preceded by a realizability check, i.e. checking 
whether a specification can be implemented. That is, check- 
ing realizability amounts to deciding whether there exists a 
set of CSAs that satisfies the specification □(A < 5) — > i^. 
If a protocol specification ip is realizable for a set of cars £ 
under a drop probability 5, this is written as SH(<^, £, 5). 

Checking realizability consists of two parts: Firstly, the 
specification itself must be well-posed, i.e. ip must admit a 
"reasonable" implementation in the form of CSAs. Secondly, 
it must be possible to find retransmission bounds so that the 
QoS requirements arc satisfied under the given drop proba- 
bility 5. 

Well-posedness is a purely syntactic requirement on the 
specification. We introduce this concept because it is easy 

to check and simplifies the presentation of the synthesis al- 
gorithm. A protocol specification p is well posed if on every 
p-sequcnco satisfying p, two ASCs take turns in triggering 
the events, and there are at least two events on each path 
through the tree induced by the specification. 

These rather strict requirements on the specifications for 
well-posedness can be relaxed by generalizing the synthe- 
sis method presented in the next section appropriately. For 
example, a straightforward relaxation would be to allow pro- 
tocol specifications in which for any disjunction piV (p2, the 
system-triggered events corresponding to the immediately 
following global events are all triggered by the same ASC. 



Wc do not develop a separate test for realizability but 
rather show how our method fails for well-posed but nonre- 
alizable specifications. 

5.2 Synthesis Algorithm 

The synthesis method is implemented in two parts: First, 
the retransmission bounds are calculated. Then the CSAs 
are constructed using the retransmission bounds. The re- 
transmission bounds are calculated with the structure of the 
resulting CSAs in mind, so we present the CSA construction 
first. 

For any specification □(A < 5) — ^ <p and any set of cars £, 
if the specification is realizable, the resulting set M of CSAs 
from the synthesis, &{ip,<t,5) must satisfy □(A < S) ip. 
Formally, 

V(p.Ve:.V5 € [Q,l].9i{<fi,€,d) ^ {&{<fi,£,S) I- □(A <6)^ <fi). 

The synthesis method & is implemented in two parts: First, 
the retransmission bounds are calculated. Then the CSAs 
are constructed using the retransmission bounds. The re- 
transmission bounds are calculated with the structure of the 
resulting CSAs in mind, so we present the CSA construction 
first. 

5.2.1 CSA Construction 

Table 3 shows the algorithm Synthesize(</5, a;, i, i7, n,^). 
This algorithm constructs the CSA Mx for car x from the 
specification (p. The parameter i is used to uniquely in- 
dex states in the CSA, and i? is a set of global events that 
is used to construct appropriate criteria for retransmission 
(explained below), is the list of retransmission bounds 
calculated in the first step (cf. Sec. 5.2.2). 

Each global event e = ex->y(d) that occurs in the pro- 
tocol specification ip is assigned an environment-triggered 
event e^^y(d), a system-triggered event (_y^x{d), a message 
vac G MSG, a variable (as retransmission counter) G V, 
a retransmission bound from n^, and system-triggered 
events T.O.e and fail ^. 

The algorithm is invoked by SYNTHESiZE(</3,a;,0, 0, n<^), 
for each car x € It synthesises a CSA for the well-posed 
protocol specification ip for car x, where states are indexed 
starting from 0, no previous events are stored {E = 0) and 
the retransmission bounds are used. 

Synthesize recursively decomposes ip into its subparts. 
If = (^1 V </92 , then two CSAs Mi and M2 are constructed 
from ipi and ip2 first and joined together by forming the 
union of their state spaces, final states and transitions and 
substituting the initial state s]^^* by the initial state s]^^*. 
For this purpose we define M[si/s2] to be the CSA M with 
all occurrences of S2 substituted by si. 

If ifi = ty^z{d) — > O'P'i the set E of global events that 
has last been received on the path through the CSA is up- 
dated first. Then again the CSA M for ip' is constructed. 
Depending on which car x the CSA is constructed for, differ- 
ent transitions are now introduced. If x = y then the ASC 
on car x is responsible for triggering the event ty^^id), and 
a retransmission loop is introduced: 



(I) 




li X = z, then car x synchronizes e by the system-triggered 
event e^^y{,d): 



(11) 




In any other case, simply the CSA for p' is returned as then 
the car x is not directly involved in the transmission. 

Finally, ii (p> = ty^^id) then no recursive call to Synthe- 
size is necessary, but a CSA is directly constructed. li x = y 
then a retransmission loop is constructed: 



(III) 



6 

In this case, a retransmission is not triggered by a timeout, 
because ty^z{d) is the last global event in a sequence of 
required synchronizations and no feedback from the car z 
can be expected. Therefore, a retransmission is initiated by 
receiving the last message /i from car z again, because this 
indicates that z has not received the message rric correctly. 
The message /j is taken from E, the set of global events that 
has last been received on the path through the CSA. Only 
if no such message is received is a timeout transition made, 
which indicates success by an upcall to the ASC. The global 
semantics of CSAs were carefully constructed so that this 
timeout is only taken if no message n is received. 

lix = z, then car x synchronizes e by the system-triggered 
event t^^y{d): 



(IV) 



■Si+r- 



^Note that x does not need to occur in the protocol specifi- 
cation ip. 



In any other case a trivial CSA with one state is returned. 

Example 1 (Continued) The resulting CSAs from syn- 
thesizing the specification in (1) are shown in Fig. 5. The 
CSAs were generated by calling SYNTHESiZE((^,a;, 0, 0, n^p) 
for X € {A,B'\. The retransmission bounds Uip are calcu- 
lated as explained in the next section according to the QoS 
requirements and to the bound on the drop probability 5. D 

5.2.2 Retransmission Bounds 

Each global event e^^y^d) gets assigned a unique message 
me G MSG and a unique retransmission bound G No. The 
retransmission bounds are evaluated according to the QoS 
requirements defined in the protocol specification ip. 

Recall that the protocol specification ip> induces a tree, cf. 
Fig. 4. Each edge of this tree is translated by the synthesis 
into a retransmission loop in the CSA of exactly one car, 
with a retransmission bound associated with that loop. The 
retransmission bounds have to be selected so that correct- 
ness as defined in Sec. 4.4 is guaranteed. 

We use the semantics to find the conditions on the re- 



Synthesize(v5, X, i, E, Uyp) 
If (p = (fii \/ (p2 Then 

(Mi,ii) = Syntiiesize((^i, x, 't, S, n.^) 
(M2,i2) = SYNTHESiZE(v52,a;,ii,i5,n^) 
Return {{Sm, U s^Sf , 5^,^ U S{,^, 

TMiUTM,>K«/s5S^1,i2) 

Else If = ey^.z(d) -5- Ov' Then 
If 3iJ,,d.fj,y^^{d) e E Then 

Replace fiy^z{d) By m^^y^z(d) In iJ 

Else 

Insert me,j,->z(d) Into S 
If a; = 2/ Then 

{M, i') = Synthesize((p', X, i + 3, E, n^) 

{TM(si,ty^^{d)) ■- Si+i 
TM{s^+l, {Um,,y^4d),U, < He)) := Sm* 
TM{Si+l, (failj, i^e > Tie)) ■■= Si+2 
Tm(s';S'*, (T.O.e, iye++)) ■= 

Return ((Sm U {sj, Sj+i, Si+2}, Sj, S'^, Tm>, i') 
Else If a: = z Then 

(M, i') = Synthesize((/?', a;, i + 1, i5, n<^) 

(II) { rM(si,(?m.,.^^(d),e,^,(d))) := s^T* 

Return {{Sm U {s;}, s,, Sij,TM),i') 

Else 

Return SYNTHESiZE(iy5', a;, i, i5, n,^) 
Else If ip = (p = €^-,z{d) Then 
If a; = y Then 

Hy^z{d) € E 

( ns,,^y^Ad)) i 

T(si+i, (!!me,y_+z(d), < "e)) := Si+2 

(III) <^ T{s,+i, (fail„J^. > n.)) := Si+3 

T(Si+2, {l^.y^z{d), Ve++)) ■■= Si+l 
I r(Si+2, (T.O.e. success ^)) := Si+4 

Return (({«,, Si+i, Si+2, Si+3, Si+4}, Si, 
{si+4},T>,i + 5) 
Else If a; = « Then 

(IV) { T{si, (?m,..^,(d), e,^^(d))) := Si+i 

Return (({si, Si+i}, Si, {si+i}, T),i + 2) 

Else 

Return (({si}, Si, {si}, 0),i + 1) 

Table 3: Pseudocode of synthesis algorithm. The 
CSA is constructed from the diagrams explained in 
the text and referred to by Roman numerals. 

transmission bounds tliat are sufficient for correctness. We 
can exploit the tree-like structure of the synthesized CSAs: 
Apart from the last two retransmission loops in each se- 
quence, the message associated with a retransmission loop 

is never used at a later point in the same sequence. 

Each sequence of global events cr = eie2 • • • ei is associated 
with a sequence of retransmission bounds rio- = Jiei . . . rie, . 
Depending on the values of the retransmission bounds, the 
sequence a is generated correctly with a certain synchroniza- 
tion probability P''{nc,) that depends on all retransmission 
bounds associated with any event in a. Note that this prob- 
ability is the likelihood of a being generated correctly given 
that the calls are made by the ASCs that generate a. 

5.2.3 Deduction of P"^ (n^) 

The synchronization probability P"^ (jia) is evaluated as 
follows: The case of only one retransmission bound {\na\ = 
1) never occurs. The case of exactly two retransmission 
bounds (ItIctI = 2) means that the last retransmission loop 



uses the message transmitted in the retransmission loop one 
before last, cf. Fig. 5. The example in this figure can be 
used to deduce the general expression for P°'(ni, 712). This is 
because the synthesis will always generate the same pattern 
for the last two global events in a specification. 

We use the sequence a = sndA^s(d)acks^A to deduce 
P" {ni, n2) by evaluating the probability of correct synchro- 
nization by applying the deduction rules in Table 1 and 
Table 2. The CSAs {A, B) = M start in the initial state 
(s^^,sf). We omit writing the values of the retransmis- 
sion counters within the states in our presentation. We let 
P°'(ni,n2) — Pi^i{ni,n2), wherep°',i('^ii "-2) are an auxiliary 
functions describing the probability of reaching a globally fi- 
nal state from (s^, sf) when the calls in a are made. 

Initially only Ma can execute by applying the [env] rule 
locally. Hence, we start the deduction at {(•)^, {si,sf),A). 
We find Pi, 1(^1,^2) by applying the global rules to deduce 
all sequences for which A4 ends in a globally final state and 
the calls in cr are made. First, apply [pr-e] globally and [env] 
locally and deduce 

{(•)\ {st,s?},A} ^M(6) {{§ndA^B{d))\ {sf, s?),A) 

globally from 

(•,st) — {snd^^ g{d), si) 

locally. This deduction step yields pf i(ni, n2) = P2,i("'i) "-2), 
as the probability is not changed from state {s]*,sf) to 
(s^,sf). From now on we omit the left hand side of the 
relation > m(S)j since it is equivalent to the right hand 
side of the previous deduction. We further omit writing the 
local deductions. 

At {s2,Si), globally only the [pr-e] rule can be applied. 
Locally, either [sys-c] or [b-c] can be applied, depending on 
the value of the retransmission counter vi. Applying [sys-c] 
corresponds to taking the transition labelled by failj^. Since 
then no final state can ever be reached, we only apply the 
[b-c] rule locally. So we apply locally the [b-c] rule: 

{{sndA^B{d)+UaA^B{d))\(si,s?),A). 

This transition leads to P2,i('^ii '^2) = P3,i(tii, W2). At this 
point the transmission medium is invoked and globally both 
the [trans] and [drop] rules can be applied. If [trans] is ap- 
plied, Mb receives the message and we apply the [r-sys] rule 
locally. If [drop] is applied, merely the probability and pri- 
oritization changes. Hence, we can deduce either 

^Mw((p+?aB^A(d) + sndB^^(d))(i-*),(s^,s?),S), or 
^M(6){{p)',{st,s?),B), 

where p = snd ^ .p(d). Since two transitions may be taken, 
wegetp3_i(rii,n2) = (l-5)pj,2('^i, M2)-l-5p3,i(rii, ^2). After 
the application of [drop], Mb is prioritized but cannot make 
a transition. In state (s3,sf), globally only [npr] can be 
applied, with Ma making a timeout transition using [to- 
upd] locally: 

{(snd^^s(d) + T.O.l)^ {st sf),A). 

Since the application of [to-upd] increases the retransmission 
counter ui by one, we get j^('«i,n2) = P2,i{i'ti ^ ^■, 'i'^2) and 
the base case P3 j^(0,n2) = 0. This indicates that in state 
(s2,Si), the deduction may be repeated with the bound 
ni decreased by one, corresponding to a retransmission. If 



ni — 0, i.e. in the base case, no more retransmissions are 

possible. 

In state (s^, ) ai^er the transmission, Mb makes a tran- 
sition in response to a call from its ASC. By applying [env] 
instead of [env'] , we model that a is made immediately. Ap- 
plying [pr-e] globally and [env] locally yields: 



>M(6) {{p + SSks^A)^^ ^\ 



{S3 , S3 I 



,B), 



where p = snd ^ ,p(d)+?aR^A(d) + snd p, ^(d). Then only 
[pr-e] with [b-c] can be applied (because again, applying [sys- 
c] does not conform with wanting to reach a final state). 
Therefore we get 



{{p+\\bB^Af-'\{st,si),B), 



(4) 



where p = snd^^g (d)+?as^A(d) -I- snd p, ^(d) + ack p^ 4. 
This generates the equalities P3,2(«'ii^2) = P3,3('^i, "■2) and 
P3,3(m,n2) =P3,5(m,n2). 

In (s3^, S5) we can apply either [trans] globally with [r-sys] 
locally on Ma, modelling a successful transmission, or we 
apply [drop] globally, modelling a dropped message. Hence 
we can either deduce 



>M(S){ip+nA^BY'-'>'^''-'\ 

>M(s){ipY'-^~^\ {si,si),A) 



{sf,si),A), or 



where p = snd ^ , g(d)+7aB-i-A(d) + sndg, ^(d) -I- ackg . 4. 
We get pf_5(Ri,n2) = (1 - 5)P5,B(m,n2) + ^3,5(^1,712). In 
state (s^, si), the sequence has been synchronized success- 
fully. Here only [npr] with [to-sys] on Mb can be applied to 
yield 



((p + T.0.2 + success o) 



(i-«)(i-«) 



{sf,si),A), 



where p = snd ^ ,g(d)+?aR^A(d) -I- sndg, ^(rf) -l-ackg , ^+ 
IbAi-B- This deduction ends in a globally final state and 
hence J35 5(711,712) — 1, because the sequence a is correctly 
synchronized. In state {s3,si) after the message has been 
dropped, only [pr-t] with [to-upd] locally on Ma can be ap- 
plied: 

^Mis) {{p + T.O.i)*(i-*\ {st si), A) 



where p = snd^^g{d)+?aB^A{d) + snd g, ^(d) + ack^^^. 
This step yields -(ni , 112) = ^2,5(7*1 — 1, 712) with base case 
P3 5(0,712) = 0. Now Ma retransmits (if its retransmission 
count is not yet exceeded) and we deduce with [pr-e] and 
[b-c] locally on Ma'- 



({p+UaA^B{d)) 



S(l-S) 



{si, si). A) 



where p = snd 4 ^ p (d)+?aB^A (d) + snd p, 4 (d) -|- ack p^ 4 + 
T.O.i. This yields p2.r)(''"'-i, '",2) = 5(711, 772)- Now [trans] 
can be applied with [r-upd] locally on Mb- However, when 
applying [drop], no final state can be reached by any se- 
quence of applications of deduction rules. Hence we only 
apply [trans] and [r-upd] and get 



>M(6) 



{(p+?aA^B{d)) 



5(l_5)(l-5) 



{stsi),A) 



where p = snd ^ _, p(d)+7aB^A (d) -I- snd p, 4 (d) -I- ackp^ 4 + 
T.O.i. This yields Pg 5(711, 712) = (1 — 5)P3,3(7ii, 7i2 — 1) with 
base case ^^,5(711, 0) = 0. 



5.2.4 Optimization Problem 

For notational convenience, we drop the a superscript if 
the context is clear and we are not referring to a particular 

sequence. When the sequence of global events a has exactly 

two elements (jcrj = 2), we get 

3 "1 

P(7ii, 712) ^ e(i - 6"^+') + Y^^T^s' [1 - {Sgr] , 

^ i=l 

where g = (1 — 5) is the locoption probability and M — 
min (m 4-1 — 7, 712). When a has more than two elements 
{\a\ > 2), the synchronization probability can be similarly 
deduced: 

P{ni,n2, ...,ni) = g J'.P(7ii - i, 712 . . . ,7i(). 



P(7ll,772, . - - ,7li) 



A ^eEf^o'5T(7^2-^,...,n^) if « > 2 



P(7ll,7l2) 



if « = 2, 



where M = min (711, 712). Ideally, we want to find the small- 
est retransmission bounds that ensure correctness. Each p- 
sequence (cr)^ that satisfies the specification <p induces a 
condition on the retransmission bounds associated with the 
elements of a. For example, a sequence (£162 - - - ^lY induces 
the condition p^i^2 . ■«( ^j^^^ ^ j^^^ , - - - , , ) > P- This inequal- 
ity ensures that the sequence a is generated by the CSAs 
with high enough probability as required by the correctness 
criterion set out above. 

We can find the retransmission bounds by solving an op- 
timization problem: 



(OPT) 



s.t. P'"(77<,) > p for all (a)^ e 



where = {(G)'^\(aY \= 'p} is the set of p-scqucnces a that 
satisfy the protocol specification tp. 

Example 1 (Continued) Checking realizability of a spec- 
ification amounts to checking well-posedness of the specifi- 
cation and feasibility of the optimization problem. For our 
example specification (1), the optimization problem is 

min Tland + 7lack + Tlnack 

s.t. P(nsnd,7lack) > Pi 

P(7lsnd,7lnack) > P2- 

In the case that pi — 0.7, P2 ~ 0.8 and 5 = 0.35, we get 

7land = 3, 71ack = 1, and Tlnack =2. □ 

5.3 Correctness of Synthesis 

Take any protocol specification ifi, drop probability bound 
5, and any p-sequence a for which [a)^ |= tp holds. Then, 
correctness of the synthesis method is established by showing 
that {^ctY^'^'^'^^ ^ where M is the result of synthesis. 

The definition of the feasible region of the optimization 
problem (OPT) contains the inequality P(na) > p for each 
such sequence a- By the semantics of protocol specifica- 
tions {q > p A (cr)^ \= tp) ^ (ay 1= (p for any sequence 
a- It is therefore sufficient to show that (a")^*-""' |= ip and 
r{a,S,M) > P{na), because then {ay^"'^'^) |= as re- 
quired to establish correctness. 

First, if the retransmission bounds Tier are part of a feasible 
solution to (OPT), then we necessarily have P{na) > p, and 



so (cr)^("'') 1= if follows from (q > p A (a)^ ^ ip) ^ {a)" ^ 
if. 

Second, we have P{na) = r{a, 5, Ai) by construction of 
P (note that the superscript a has been dropped from P'^): 
r{a,S,A4) is the sum of all probabilities p for which [p] = 
a A {pY \= M{5), i.e. the environment-triggered events and 
system-triggered events in p synchronize to the sequence of 
global events a and the p-sequence {pY is generated by M 
and drop probability 5. By definition, (p)^ |= M{S) 
3sf G Si,3x,y G e:.((.)\ s^^*, x> =»X,(,) (W^s^y). 
It is therefore sufficient to show that in the deduction of 
the expression for Pin^) exactly those p-sequences {pY are 
taken into account that end in a globally final state £ Sj^ 
(the prioritization of x and y can safely be ignored) and for 
which |p] = a. 

The deduction of P{nc,) in Sec. 5.2.3 is essentially done by 
constructing a product automaton of all CSAs in M using 
the global semantics, and adding the probabilities along all 
paths that end in a globally final state corresponding to the 
sequence a having been executed. 

Note that it would have been enough to show P{nc) < 
r{a, 5, A4). A synthesis method that generates CSAs with 
P{na) = would be perfectly correct, but not very useful: 
The larger P{nc,) gets, the greater the feasible region of 
(OPT) gets and the more specifications can be synthesized. 
So by having P{ncr) = r{a,S,M), we have maximized the 
capabilities of the synthesis method. 

5.4 Computational Considerations 

The time required to generate a CSA from a protocol spec- 
ification LP by the Synthesize algorithm is proportional to 
the number of global events and disjunctions (V) in p (ig- 
noring the set operations on E), which can easily be seen 
from Table 3, where the implementation of Synthesize is 
shown as a simple structural recursion on Lp. When also the 
set operations on E are taken into account, the algorithm is 
quadratic in the number of global events in p. 

The main computational complexity arises from the opti- 
mization problem OPT, which is an integer program and in 
general is NP-hard. There are however a few points to be 
noted that may simplify finding a solution. First, both the 
objective function and the function P'^in^) are monotonous 
in their arguments along any dimension. Hence, if OPT is 
feasible for some n — {n^-^ , n^^ , . • . , ?ie, ) , it is also feasible for 
any n' > n. 

Second, since correctness depends on P'^ijia) < r{(T,5, M), 
it is sufficient to solve an optimization problem with a strictly 
smaller feasible set than that of (OPT). This is helpful if a 
function Q"^ can be found s.t. for all cr, Q''{na) < P'^ina) 
while still maintaining that there exist retransmission bounds 
rio- s.t. Q'^ijicr) > p for all [oY € S,p. The solution to the 
resulting optimization problem might not be optimal, but 
the resulting CSAs are still correct. 

Lastly, since any suboptimal solution to OPT still gives 
rise to correct CSAs, the retransmission bounds may be cho- 
sen to be arbitrarily high as long as they are feasible. Note 
however that there might not be a solution to OPT at all, 
in which case the specification was unrealizable in the first 
place. 

5.5 Discussion 

The implementations of a communication protocol spec- 
ification provide the ASCs with sufficient information on 




Figure 6: Feasible region of OPT for the protocol 
specification in (1) with pi = P2 = 0.9. The drop 
probability bound 5 is calculated as a function of A*", 
dmax and r„im. All points on and under the surface 
are feasible. 

what messages are received so that accidents can effectively 
be prevented. In this section we develop the continuing ex- 
ample of the cars at an intersection further by explaining 
how our protocol can be embedded in an active safety ap- 
plication. 

Example 1 (Continued) When transmitting data d from 
car A to car B, six cases can occur. We distinguish the cases 
by the final system-triggered events that generate upcalls to 
the ASCs on either car. The case we call "correct" is when 
B receives d, A knows about it and B assumes correctly 
that A knows. B then correctly receives a " success " upcall, 
which is consistent with A^s last upcall. The ASCs can then 
correctly react in a consistent way, e.g. by one car gracefully 
decelerating. 

In other cases the ASCs can still react in a safe way even if 
A and B have inconsistent information about each other: If 
B receives d correctly, A never receives an acknowledgement 
and B assumes A never did, then both ASCs receive "fail" 
upcalls and can react accordingly. If B receives d correctly 
and A receives the acknowledgement, but B assumes A did 
not receive it, then B receives a "fail" upcall and can react 
conservatively. If B does not receive d and A holds that it 
did not, then the ASC on A can react conservative on its 
" fail " upcall. If B receives d correctly, A misses the acknowl- 
edgement but B holds that A received it, then A incorrectly 
assumes the worst case but yet reacts conservatively. 

The only problematic case is when B does not receive d 
but A holds that it did. Then the ASC on neither A nor 
B takes conservative action, potentially resulting in an acci- 
dent. However, the synthesis method constructs the CSAs so 
that this case never occurs under the given assumptions. □ 

We now conclude the example by presenting numerical 
results that illustrate in which hypothetical scenarios proto- 
cols that we are considering are realizable. 

Example 1 (Continued) As introduced above, the drop 
probability bound 5 on the transmission medium may be cal- 
culated from other more readily available parameters. The 
realizability of a given protocol specification ip depends on 
the drop probability bound 5. For demonstrative purposes, 
we calculate 5 from the number of cars A'^ at the intersec- 
tion that may use the transmission medium simultaneously, 



the minimum time Tmin it may take for a message to be 
sent between two cars and the maximum amount of data 
draax that may be carried in a message. Given an empir- 
ically obtained function 6{r) that maps a data-rate r to a 
drop-probability of the transmission medium, we calculate 
5(r) with r = (N — 2)d.,nax/Trnin (wc takc N — 2 'AS wc con- 
sider the environment to be all cars except the two that are 
communicating) . 

We illustrate the effectiveness of our synthesis method by 
asserting the sigmoid 5{r) = {1 + a ■ exp(— 6r)) with a = 4 
and h = 0.002. Using the protocol specification in (1), we 
illustrate how realizability changes with different values for 
the number of cars N, minimum time to deliver a message 
Tmin and maximum amount of data in a message dmax- Fig. 
6 shows the feasible region of (OPT) for ip with pi = P2 = 
0.9, i.e. for which values of 5 calculated as a function of N, 
Tmin and dmax the synthesis problem is realizable. 

It is clearly visible from Fig. 6 that the more cars are 
sharing the transmission medium, the smaller the delay, 
and the larger the packets, the higher the worst-case data 
rate could be on the network, and the specification becomes 
harder to realize. If moreover the requirements pi and p2 
are made more stringent, the feasible region decreases even 
further. □ 

6. CONCLUSION 

This work demonstrates a framework for reliable commu- 
nication protocols for intervehicular communication in ac- 
tive safety applications. The framework, consisting of a pre- 
cisely defined specification language and execution model 
(in the form of CSAs), allows for correct-by-construction 
synthesis of protocol implementations that satisfy the spec- 
ifications even in the presence of several other cars sharing 
the transmission medium. 

In our synthesis method we only take into account the 
drop probability of the transmission medium and assume 
that this is sufficient to synthesise reliable protocols. This 
also only enables to guarantee QoS requirements on the re- 
ception probability. Furthermore, in the current formula- 
tion, only two cars can participate in a dialogue, but some 
active safety applications might require to extend this. Also, 
note that if a communication is under way, the arrival of 
another message cannot directly be handled even if it is re- 
quired to satisfy the QoS requirements. 

Our approach permits several extensions: (i) Allowing 
the higher level to specify the QoS requirements and the 
destination address at runtime (i.e. for each transmission), 
(ii) Guaranteeing QoS requirements on the end-to-end de- 
lay of the communication and more general assumptions on 
the transmission medium dynamics in order to widen the 
range of applicability, and (iii) including the capability to 
relay messages over several cars to create a routed network. 
The latter would also require a rigorously developed synthe- 
sis method for protocols to discover the network topology, 
which we are currently working on. 
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